From dona@tridelta.com  Thu Sep 05 09:40:47 1996
Received: from wariat.apk.net (uucp@wariat.wariat.org [192.147.147.1]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id JAA24412 for <hfsig@tapr.org>; Thu, 5 Sep 1996 09:40:46 -0500 (CDT)
Received: (from uucp@localhost) by wariat.apk.net (8.7.5/8.7.3) id KAA19650 for hfsig@tapr.org; Thu, 5 Sep 1996 10:41:16 -0400 (EDT)
>Received: from sparcy.tridelta.com (sparcy [192.160.168.222]) by tdi3.tridelta.com (8.6.9/8.6.9) with ESMTP id KAA13603 for <hfsig@tapr.org>; Thu, 5 Sep 1996 10:18:39 -0400
Received: from sparcy.tridelta.com (sparcy [192.160.168.222]) by tdi3.tridelta.com (8.6.9/8.6.9) with ESMTP id KAA13603 for <hfsig@tapr.org>; Thu, 5 Sep 1996 10:18:39 -0400
Received: from donapc.tridelta.com (donapc.tridelta.com [192.160.168.70]) by sparcy.tridelta.com (8.7.1/8.7.1) with SMTP id KAA22674 for <hfsig@tapr.org>; Thu, 5 Sep 1996 10:19:11 -0400 (EDT)
Date: Thu, 5 Sep 1996 10:19:11 -0400 (EDT)
Message-Id: <199609051419.KAA22674@sparcy.tridelta.com>
X-Sender: dona@sparcy
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
To: hfsig@tapr.org
From: dona@tridelta.com (Don Adams)
Content-Type: text/plain; charset="us-ascii"


I've been searching the internet for a few evenings.
 I found some abstracts 
at http://sun4.iaee.tuwien.ac.at/jb9495/ber20002.html
 http://www.ee.ed.ac.uk/profiles/research/SaS/SaS-info.html
that were interesting concerning a RAKE tracking filter.(?!)  
It claims to be a filter or corrolator
that needed "no prior knowledge of the signal".  and can
correct multipath distortion.

Does anyone know what this really is?

Over and Out  Don


From karn@qualcomm.com Thu Sep 05 13:55:18 1996
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id NAA14834 for <hfsig@tapr.org>; Thu, 5 Sep 1996 13:55:15 -0500 (CDT)
Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id LAA12594; Thu, 5 Sep 1996 11:54:43 -0700 (PDT)
Date: Thu, 5 Sep 1996 11:54:43 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199609051854.LAA12594@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <199609051419.KAA22674@sparcy.tridelta.com> (dona@tridelta.com)
Subject: Re: [HFSIG:1522]

Don,

I haven't looked at the article yet, but a RAKE receiver is a multichannel
spread spectrum receiver that tracks the individual multipath components
of a signal and then combines them before demodulation. We rely pretty
heavily on them in Qualcomm's IS-95 CDMA system.

The basic idea of a RAKE dates from the late 1950s.

To resolve individual multipath components, the time delay between
them must be at least one chip. This corresponds to a spreading
bandwidth equal to or greater than the reciprocal of the delay.

Alternatively, this corresponds to the spreading bandwidth being
greater than the coherence bandwidth of the channel. Think of the
channel as imposing a time-varying comb filter on your signal. If the
signal is wide compared to the frequency interval between the "teeth"
of the comb, then the comb is very unlikely to remove all of the
signal at once.  This is frequency diversity in action.

I don't know of any way that a RAKE receiver can be used on a
narrowband signal. If the narrowband signal falls into one of the
notches in the comb, nothing can bring it back. You then need other
forms of diversity (time, space).

Phil

From Robert.Glassey@nmp.nokia.com Tue Sep 10 05:49:56 1996
Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id FAA17673 for <hfsig@tapr.org>; Tue, 10 Sep 1996 05:49:44 -0500 (CDT)
From: Robert.Glassey@nmp.nokia.com
Received: from samail01.nmp.nokia.com (samail01.nmp.nokia.com [131.228.240.6]) by noknic.nokia.com (8.6.9/8.6.9) with ESMTP id LAA20659 for <hfsig@tapr.org>; Tue, 10 Sep 1996 11:10:30 +0300
Received: from  by samail01.nmp.nokia.com with SMTP
	(1.37.109.16/16.2) id AA055183107; Tue, 10 Sep 1996 11:11:48 +0300
X-Openmail-Hops: 2
Date: Mon, 9 Sep 96 18:09:52 +0100
Message-Id: <H000029202618415@MHS>
Subject: Johan's modem
Mime-Version: 1.0
To: hfsig@tapr.org
Content-Type: text/plain; charset=ISO-8859-1; name="Johan's"
Content-Transfer-Encoding: 7bit

Hi,

I downloaded the WAV files of Johan's modem waveforms. I've been able to
load them into matlab, and I can see the 4 modulated tones, and I can
see amplitude and phase modulation on each one, but I cannot extract any
symbol timing or see any obvious constalation, no mater how I vary the
reference carrier frequency. I can see paterns that repeat after a short
time, but can't make any sense out of them. It would help if the data
was longer and more random.

Can you demodulate this waveform? if so how? What do you lock to? Is
there a proper constalation?

Cheers,

Rob, G0VTQ

From forrerj@peak.org  Tue Sep 10 11:27:00 1996
Received: from PEAK.ORG (root@PEAK.ORG [198.68.22.17]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id LAA00317 for <hfsig@tapr.org>; Tue, 10 Sep 1996 11:26:58 -0500 (CDT)
Received: from p05.t0.monrotel.com (p05.t0.monrotel.com [198.68.25.38]) by PEAK.ORG (8.6.13/8.6.7) with SMTP id JAA20048 for <hfsig@tapr.org>; Tue, 10 Sep 1996 09:26:59 -0700
Message-Id: <199609101626.JAA20048@PEAK.ORG>
X-Sender: forrerj@peak.org (Unverified)
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 10 Sep 1996 09:20:30 -0800
To: hfsig@tapr.org
From: forrerj@peak.org (Johan Forrer)
Subject: Re: [HFSIG:1524] Johan's modem

>Hi,
>
>I downloaded the WAV files of Johan's modem waveforms. I've been able to
>load them into matlab, and I can see the 4 modulated tones, and I can
>see amplitude and phase modulation on each one, but I cannot extract any
>symbol timing or see any obvious constalation, no mater how I vary the
>reference carrier frequency. I can see paterns that repeat after a short
>time, but can't make any sense out of them. It would help if the data
>was longer and more random.
>
>Can you demodulate this waveform? if so how? What do you lock to? Is
>there a proper constalation?
>
>Cheers,
>
>Rob, G0VTQ
>
>

Hi Rob,

Pleased to see your interest in the waveforms. A few suggestions that may
put you on the right track:

I do have demodulators that goes with each of the sample waveforms, so rest
assured, the signals can be demodulated and produce text-book constellations.
All the waveforms are QPSK, so you need a QPSK demodulator(s). You may use
coherent or non-coherent demodulation, and as the S/N is very good, you
should have no problem to phase lock - at least I that is my experience. For
detection, a matched filter works best, also keep in mind that these are
RC-shaped pulses. 

All waveforms has 
        a) a pre-amble, where the phase is stepped 90 degree per symbol (75
baud rate), 
        b) followed by a number of cycles 000/001/010/011/100/....

Since I have provided the baseband waveforms, here are the carrier tones that I
used:

Waveform 1: 1350 Hz              ( single channel   DQPSK)
         2: 1350/1500 Hz         ( dual   channel   DQPSK)
         3: 1350/1500/1650/1800  ( quad   channel   DQPSK -- QUATOR)

As you may notice form above, the tones are spaced at 2*Baudrate and there
are eight phases on each carrier tone. 

I would suggest you start off with the single channel waveform, extract and
study the I/Q waveform relationship, especially the pre-amble which will
reveal a lot.

For folks attending the DCC next week; a brief overview of QUATOR is planned
for the HFSIG meeting. I'll show some ideas of how the bit assembly is to be
done for achieving the time/frequency diversity. Keep in mind that things
are experimental and things are wide open for suggestions/critisism. This is
your opportunity to bring your ideas for further discussion.

As far as the actual implementation, at least what I am doing; I have been
using the PSA sound card platform thus far. This seems to have worked out
exteremely well for coding various parts of the modem, i.e., for monitoring
the workings of things like Costas loops and bit sync algorithms. 
For the future, however, I'm not sure which way I'll go. My experience with
the new TI 320C31 DSK has been very encouraging - perhaps too little memory,
but it is really nice for the task, the speed and dynamic range, and a high
speed connection with the PC. This would make an ideal free-standing
implementation. On the other hand, I'm tempted to develop on the PC using
the soundblaster, but that would have no chance of ever getting the the ARQ
mode to work. I will, however, be able to play with the broadcast and CSMA
modes. 
I'll need to see how things develop - too much going on at the moment and
the new modem have been on the shelf due to that. Would be nice to resume
experimental work again.

Much rambling, but hope this helps,

--Johan

From karn@qualcomm.com Tue Sep 10 18:03:54 1996
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id SAA18220 for <hfsig@tapr.org>; Tue, 10 Sep 1996 18:03:52 -0500 (CDT)
Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id QAA07499; Tue, 10 Sep 1996 16:03:20 -0700 (PDT)
Date: Tue, 10 Sep 1996 16:03:20 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199609102303.QAA07499@servo.qualcomm.com>
To: hfsig@tapr.org
Subject: coding progress

Hello all,

I've been rather quiet here of late so I thought I'd mention what I've
been doing in my spare time over the past couple of weeks.

I've continued to fine-tune my Viterbi decoder for speed and Eb/N0
performance.

My previous version uses the "register exchange" method to update the
path histories. This limited the path history to 32 bits, the size of
a long integer in C. This is barely adequate as the rule-of-thumb says
that the path history should be at least 4-5 times the constraint length
(K=7), longer if the code is going to be punctured to high rates.

I rewrote my current version to use the traceback method. In this
case, the path histories are saved all the way from the beginning of
the packet. At the end of the packet, I "trace back" through the path
memory to determine the decoded data. Although this version is
packet-oriented at present, it shouldn't be too hard to modify to
operate in a continuous stream mode where traceback is done every N
bits (N >> K).

I've also spent quite a bit of effort tuning up the Viterbi decoder
for speed. Through a few more C coding tricks, I now have it running
at 258 kb/s on a 133 MHz Pentium. (The compiler is GCC 2.7.2 with full
optimization).

Thanks to my success with fast Viterbi decoding I've gotten more
interested of late in concatenated Reed-Solomon/Viterbi coding. These
codes were used on the Voyager mission starting at Uranus, and they
are now an integral part of digital satellite broadcasting (European
DVB, US DSS).

In terms of Eb/N0 they perform about as well as sequential decoding
but with more uniform computational effort. The BER curve for the
Voyager code is a nearly vertical wall at a Eb/N0 of about 2.5 dB.
The Voyager outer code is a (255,223) RS code over GF(256), and the
inner code is a rate 1/2 K=7 Viterbi-decoded convolutional code.  DVB
uses a shortened (204,188) RS outer code and a K=7 Viterbi inner code
at various rates from 1/2 to 7/8, so it's not quite as strong as the
Voyager code but is still quite good.

This has gotten me interested in Reed-Solomon codes. I found some
freely available C code on the net by Robert Morelos-Zaragoza and Hari
Thirmoorthy of the University of Hawaii that does errors+erasures
decoding of Reed-Solomon codes. I've been massaging it for speed and
interface cleanliness. I now have it decoding the Voyager (255,223) RS
code over GF(256) at about 850 kb/s with a full load of errors and
erasures, and about twice that speed when the frame has no errors.

I'll put both my new Viterbi decoder and the RS stuff up on my web page
in a few days when I package it up.

Phil

From wb4gcs@amsat.org Tue Sep 10 19:34:25 1996
Received: from mh004.infi.net (mh004.infi.net [198.22.1.119]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id TAA22911 for <hfsig@tapr.org>; Tue, 10 Sep 1996 19:34:21 -0500 (CDT)
Received: from PENTIUM by mh004.infi.net with SMTP 
	(Infinet-S-3.3) id UAA28238; Tue, 10 Sep 1996 20:34:12 -0400 (EDT)
Message-Id: <1.5.4.32.19960911003350.8c5091dc@infi.net>
X-Sender: jsanford@infi.net
X-Mailer: Windows Eudora Light Version 1.5.4 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 10 Sep 1996 20:33:50 -0400
To: hfsig@tapr.org
From: Jim Sanford <wb4gcs@amsat.org>
Subject: Re: [HFSIG:1525] Re: Johan's modem

At 11:28 AM 9/10/96 -0500, you wrote:
>>Hi,
>>
>>I downloaded the WAV files of Johan's modem waveforms. I've been able to
>>load them into matlab, and I can see the 4 modulated tones, and I can
>>see amplitude and phase modulation on each one, but I cannot extract any
>>symbol timing or see any obvious constalation, no mater how I vary the
>>reference carrier frequency. I can see paterns that repeat after a short
>>time, but can't make any sense out of them. It would help if the data
>>was longer and more random.
>>
>>Can you demodulate this waveform? if so how? What do you lock to? Is
>>there a proper constalation?
>>
>>Cheers,
>>
>>Rob, G0VTQ
>>
>>
>
>Hi Rob,
>
>Pleased to see your interest in the waveforms. A few suggestions that may
>put you on the right track:
>
>I do have demodulators that goes with each of the sample waveforms, so rest
>assured, the signals can be demodulated and produce text-book constellations.
>All the waveforms are QPSK, so you need a QPSK demodulator(s). You may use
>coherent or non-coherent demodulation, and as the S/N is very good, you
>should have no problem to phase lock - at least I that is my experience. For
>detection, a matched filter works best, also keep in mind that these are
>RC-shaped pulses. 
>
>All waveforms has 
>        a) a pre-amble, where the phase is stepped 90 degree per symbol (75
>baud rate), 
>        b) followed by a number of cycles 000/001/010/011/100/....
>
>Since I have provided the baseband waveforms, here are the carrier tones that I
>used:
>
>Waveform 1: 1350 Hz              ( single channel   DQPSK)
>         2: 1350/1500 Hz         ( dual   channel   DQPSK)
>         3: 1350/1500/1650/1800  ( quad   channel   DQPSK -- QUATOR)
>
>As you may notice form above, the tones are spaced at 2*Baudrate and there
>are eight phases on each carrier tone. 
>
>I would suggest you start off with the single channel waveform, extract and
>study the I/Q waveform relationship, especially the pre-amble which will
>reveal a lot.
>
>For folks attending the DCC next week; a brief overview of QUATOR is planned
>for the HFSIG meeting. I'll show some ideas of how the bit assembly is to be
>done for achieving the time/frequency diversity. Keep in mind that things
>are experimental and things are wide open for suggestions/critisism. This is
>your opportunity to bring your ideas for further discussion.
>
>As far as the actual implementation, at least what I am doing; I have been
>using the PSA sound card platform thus far. This seems to have worked out
>exteremely well for coding various parts of the modem, i.e., for monitoring
>the workings of things like Costas loops and bit sync algorithms. 
>For the future, however, I'm not sure which way I'll go. My experience with
>the new TI 320C31 DSK has been very encouraging - perhaps too little memory,
>but it is really nice for the task, the speed and dynamic range, and a high
>speed connection with the PC. This would make an ideal free-standing
>implementation. On the other hand, I'm tempted to develop on the PC using
>the soundblaster, but that would have no chance of ever getting the the ARQ
>mode to work. I will, however, be able to play with the broadcast and CSMA
>modes. 
>I'll need to see how things develop - too much going on at the moment and
>the new modem have been on the shelf due to that. Would be nice to resume
>experimental work again.
>
>Much rambling, but hope this helps,
>
>--Johan
>
>
Johan:
PLEASE stay with the PSA chip set . . . . . ..
73, Jim
wb4gcs@amsat.org
>

From forrerj@peak.org  Tue Sep 10 21:32:43 1996
Received: from PEAK.ORG (root@PEAK.ORG [198.68.22.17]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id VAA27161 for <hfsig@tapr.org>; Tue, 10 Sep 1996 21:32:40 -0500 (CDT)
Received: from p05.t0.monrotel.com (p04.t0.monrotel.com [198.68.25.37]) by PEAK.ORG (8.6.13/8.6.7) with SMTP id TAA27279 for <hfsig@tapr.org>; Tue, 10 Sep 1996 19:32:44 -0700
Message-Id: <199609110232.TAA27279@PEAK.ORG>
X-Sender: forrerj@peak.org (Unverified)
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 10 Sep 1996 19:26:30 -0800
To: hfsig@tapr.org
From: forrerj@peak.org (Johan Forrer)
Subject: Re: [HFSIG:1526] coding progress

Phil,

Nice progress - I am looking forward to downloading the latest versions of
the decoders.

A bit of feedback if you're interested - I have had a bash at converting the
Fano decoder to run under MS VC++ version 4.0. This is for the NT/WIN95
32-bit platform. I found that there are a number of routines that are common
UNIX or GCC, but are missing from the MS libraries. I'll post something
about this, but perhaps see your latest version first.

Keep up the good work!

--Johan 


>Hello all,
>
>I've been rather quiet here of late so I thought I'd mention what I've
>been doing in my spare time over the past couple of weeks.
>
>I've continued to fine-tune my Viterbi decoder for speed and Eb/N0
>performance.
>
>My previous version uses the "register exchange" method to update the
>path histories. This limited the path history to 32 bits, the size of
>a long integer in C. This is barely adequate as the rule-of-thumb says
>that the path history should be at least 4-5 times the constraint length
>(K=7), longer if the code is going to be punctured to high rates.
>
>I rewrote my current version to use the traceback method. In this
>case, the path histories are saved all the way from the beginning of
>the packet. At the end of the packet, I "trace back" through the path
>memory to determine the decoded data. Although this version is
>packet-oriented at present, it shouldn't be too hard to modify to
>operate in a continuous stream mode where traceback is done every N
>bits (N >> K).
>
>I've also spent quite a bit of effort tuning up the Viterbi decoder
>for speed. Through a few more C coding tricks, I now have it running
>at 258 kb/s on a 133 MHz Pentium. (The compiler is GCC 2.7.2 with full
>optimization).
>
>Thanks to my success with fast Viterbi decoding I've gotten more
>interested of late in concatenated Reed-Solomon/Viterbi coding. These
>codes were used on the Voyager mission starting at Uranus, and they
>are now an integral part of digital satellite broadcasting (European
>DVB, US DSS).
>
>In terms of Eb/N0 they perform about as well as sequential decoding
>but with more uniform computational effort. The BER curve for the
>Voyager code is a nearly vertical wall at a Eb/N0 of about 2.5 dB.
>The Voyager outer code is a (255,223) RS code over GF(256), and the
>inner code is a rate 1/2 K=7 Viterbi-decoded convolutional code.  DVB
>uses a shortened (204,188) RS outer code and a K=7 Viterbi inner code
>at various rates from 1/2 to 7/8, so it's not quite as strong as the
>Voyager code but is still quite good.
>
>This has gotten me interested in Reed-Solomon codes. I found some
>freely available C code on the net by Robert Morelos-Zaragoza and Hari
>Thirmoorthy of the University of Hawaii that does errors+erasures
>decoding of Reed-Solomon codes. I've been massaging it for speed and
>interface cleanliness. I now have it decoding the Voyager (255,223) RS
>code over GF(256) at about 850 kb/s with a full load of errors and
>erasures, and about twice that speed when the frame has no errors.
>
>I'll put both my new Viterbi decoder and the RS stuff up on my web page
>in a few days when I package it up.
>
>Phil
>
>

From edu@kender.es Wed Sep 11 13:39:22 1996
Received: from kender.es (kender.es [194.179.91.10]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id NAA08124 for <hfsig@tapr.org>; Wed, 11 Sep 1996 13:38:55 -0500 (CDT)
Received: from tximbo.kender.es (p4.kender.es [194.179.91.53]) by kender.es (8.7.5/8.7.3) with SMTP id UAA13498 for <hfsig@tapr.org>; Wed, 11 Sep 1996 20:33:53 +0200
Message-Id: <1.5.4.32.19960911213841.0067b2b4@kender.es>
X-Sender: edu@kender.es (Unverified)
X-Mailer: Windows Eudora Light Version 1.5.4 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 11 Sep 1996 20:38:41 -0100
To: hfsig@tapr.org
From: Eduardo Jacob <edu@kender.es>
Subject: Re: coding progress

>A bit of feedback if you're interested - I have had a bash at converting the
>Fano decoder to run under MS VC++ version 4.0. This is for the NT/WIN95
>32-bit platform. I found that there are a number of routines that are common
>UNIX or GCC, but are missing from the MS libraries. I'll post something
>about this, but perhaps see your latest version first.

        I have read in DDJ that there is a port of GNU-C to Windows'95,
perhaps you could use it. I don't remember very well but I think the missing
parts were those related to the GUI. For dos perhaps DDJ could suit you.

        Eduardo EA2BAJ
     Eduardo, EA2BAJ

From karn@qualcomm.com Wed Sep 11 17:41:33 1996
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id RAA18624 for <hfsig@tapr.org>; Wed, 11 Sep 1996 17:41:31 -0500 (CDT)
Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id PAA18109; Wed, 11 Sep 1996 15:40:58 -0700 (PDT)
Date: Wed, 11 Sep 1996 15:40:58 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199609112240.PAA18109@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <1.5.4.32.19960911213841.0067b2b4@kender.es> (message from Eduardo Jacob on Wed, 11 Sep 1996 13:48:17 -0500 (CDT))
Subject: Re: [HFSIG:1529] Re: coding progress

>>A bit of feedback if you're interested - I have had a bash at converting the
>>Fano decoder to run under MS VC++ version 4.0. This is for the NT/WIN95
>>32-bit platform. I found that there are a number of routines that are common
>>UNIX or GCC, but are missing from the MS libraries. I'll post something
>>about this, but perhaps see your latest version first.

I'm a little confused by this, as the Fano decoder is just a low level
subroutine that doesn't make use of anything elaborate in the
operating environment. It should port to just about any C environment.

>        I have read in DDJ that there is a port of GNU-C to Windows'95,
>perhaps you could use it. I don't remember very well but I think the missing
>parts were those related to the GUI. For dos perhaps DDJ could suit you.

There is a port of GNU-C to DOS called DJGPP that I'm pretty familiar with.
A few weeks ago I released a port of KA9Q NOS to DJGPP; it's up on my web
page. Are you saying there is specific support for windows 95 in graphics
(not dos) mode?

Phil

From forrerj@peak.org  Thu Sep 12 01:36:40 1996
Received: from PEAK.ORG (root@PEAK.ORG [198.68.22.17]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id BAA12248 for <hfsig@tapr.org>; Thu, 12 Sep 1996 01:36:38 -0500 (CDT)
Received: from p01.t0.monrotel.com (p01.t0.monrotel.com [198.68.25.34]) by PEAK.ORG (8.6.13/8.6.7) with SMTP id XAA12565 for <hfsig@tapr.org>; Wed, 11 Sep 1996 23:36:45 -0700
Message-Id: <199609120636.XAA12565@PEAK.ORG>
X-Sender: forrerj@peak.org (Unverified)
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 11 Sep 1996 23:30:28 -0800
To: hfsig@tapr.org
From: forrerj@peak.org (Johan Forrer)
Subject: Re: [HFSIG:1530] Re: coding progress

Hi Phil,

Here are more specifics that may help;

>>>A bit of feedback if you're interested - I have had a bash at converting the
>>>Fano decoder to run under MS VC++ version 4.0. This is for the NT/WIN95
>>>32-bit platform. I found that there are a number of routines that are common
>>>UNIX or GCC, but are missing from the MS libraries. I'll post something
>>>about this, but perhaps see your latest version first.
>
>I'm a little confused by this, as the Fano decoder is just a low level
>subroutine that doesn't make use of anything elaborate in the
>operating environment. It should port to just about any C environment.
>

I'm using VC version 4.0 (4.2 is the latest): 

Metrics.c: erf() .... not recognized perhaps there is an equivalent.

           M_SQRT2, M_LOG2E .... not recognized - these are UNIX/GCC natives.

Sim.c:     random() ... does'nt recognize this either.

Of course, curses does'nt exsist, but one can work around that. Otherwise
the function you use to parse your command-line arguments also doesn't have
an equivalent. There are a few minor picky warnings regarding type casting
that I agree with the compiler, but won't hurt.


>>        I have read in DDJ that there is a port of GNU-C to Windows'95,
>>perhaps you could use it. I don't remember very well but I think the missing
>>parts were those related to the GUI. For dos perhaps DDJ could suit you.
>
>There is a port of GNU-C to DOS called DJGPP that I'm pretty familiar with.


Yes - the makefile for the Fano decoder and test programs all compile/link
and execute 100% with DJGPP - either under DOS or a DOS box under WIN95.

>A few weeks ago I released a port of KA9Q NOS to DJGPP; it's up on my web
>page. Are you saying there is specific support for windows 95 in graphics
>(not dos) mode?
>
>Phil
>
>

I suspect he might be referring to that it is for generating Win95 "console"
mode code, i.e., 32-bit programs that run in a Win95 DOS box. These do not
use the Windows GUI functions. 

DJGPP is very slick and I like it a lot. My main objection with DJGPP,
however, is when one venture into doing hardware access, which is what we
used to used to do with DOS programs - DJGPP does that with with nasty old
DPMI calls that I really discourage anyone to use. I personally feel that I
would want to move away from DOS and things like DOS extenders and the
limitations of 64K segments. The right way, in my humble opinion, is to bite
the bullet and write your own VxDs to do that kind of thing using the native
mechanisms provided by the operating system. This way one can control and
guarantee interrupt latency and control the flow of data/control between
Win95-based programs and real-time, low-level, device dependant code. Not
that I think Win95 is all that great a piece of code, but I suspect that any
code that will run under that platform will enjoy that much greater appeal
in the ham community and get folks interested. If that was'nt the case, I
would prefer to do all my work under Linux
(my two-cents worth).

--Johan

From jmorriso@bogomips.com  Thu Sep 12 02:20:42 1996
Received: from orange.ConcordPacific.Com (root@orange.ConcordPacific.com [204.239.26.10]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id CAA13155 for <hfsig@tapr.org>; Thu, 12 Sep 1996 02:20:39 -0500 (CDT)
Received: from bogomips.com (root@jmorriso.multiactive.com [204.239.26.200]) by orange.ConcordPacific.Com (8.6.12/8.6.12) with SMTP id AAA20114 for <hfsig@tapr.org>; Thu, 12 Sep 1996 00:20:59 -0700
Received: by bogomips.com (Linux Smail3.1.29.1 #3)
	id m0v162e-000TyBC; Thu, 12 Sep 96 00:18 PDT
Message-Id: <m0v162e-000TyBC@bogomips.com>
From: jmorriso@bogomips.com (John Paul Morrison)
Subject: Re: [HFSIG:1530] Re: coding progress
To: hfsig@tapr.org
Date: Thu, 12 Sep 1996 00:18:28 -0700 (PDT)
In-Reply-To: <199609112240.PAA18109@servo.qualcomm.com> from "Phil Karn" at Sep 11, 96 05:55:46 pm
X-Bogomips: 33.55
Content-Type: text

> 
> I'm a little confused by this, as the Fano decoder is just a low level
> subroutine that doesn't make use of anything elaborate in the
> operating environment. It should port to just about any C environment.
> 
> >        I have read in DDJ that there is a port of GNU-C to Windows'95,
> >perhaps you could use it. I don't remember very well but I think the missing
> >parts were those related to the GUI. For dos perhaps DDJ could suit you.
> 
> There is a port of GNU-C to DOS called DJGPP that I'm pretty familiar with.
> A few weeks ago I released a port of KA9Q NOS to DJGPP; it's up on my web
> page. Are you saying there is specific support for windows 95 in graphics
> (not dos) mode?

Cygnus support sponsored a port to Windows NT, plus compatibility
libraries to make UNIX programs easy to port. Windows 95 implements
some of the Windows NT (Win32) API, so it runs under that too
(but not as well apparently).

I think it can only do console mode (ie text), more code needs
to be written so GCC can create GUI apps.

> 
> Phil
> 
> 

---------------------------------------------------------------------------
BogoMIPS Research Labs  --  bogosity research & simulation  --  VE7JPM  -- 
  jmorriso@bogomips.com  ve7jpm@ve7jpm.ampr.org  jmorriso@ve7ubc.ampr.org
---------------------------------------------------------------------------

From jtpjatae@bicc00.bi.ehu.es Thu Sep 12 05:47:31 1996
Received: from bicc00.bi.ehu.es (bicc00.bi.ehu.es [158.227.65.40]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id FAA18245 for <hfsig@tapr.org>; Thu, 12 Sep 1996 05:47:24 -0500 (CDT)
Received: from bipt71.bi.ehu.es by bicc00.bi.ehu.es (AIX 3.2/UCB 5.64/4.03)
          id AA21376; Thu, 12 Sep 1996 12:49:14 +0100
Message-Id: <9609121149.AA21376@bicc00.bi.ehu.es>
Comments: Authenticated sender is <jtpjatae@bicc00.bi.ehu.es>
From: "Eduardo Jacob" <jtpjatae@bicc00.bi.ehu.es>
Organization: ETSII y de IT, Bilbao, UPV/EHU
To: hfsig@tapr.org
Date: Thu, 12 Sep 1996 12:47:06 +0000
Subject: Re: coding progress
Reply-To: jtpjatae@bicc00.bi.ehu.es
Priority: normal
X-Mailer: Pegasus Mail for Win32 (v2.42a)

> >        I have read in DDJ that there is a port of GNU-C to Windows'95,
> >perhaps you could use it. I don't remember very well but I think the missing
> >parts were those related to the GUI. For dos perhaps DDJ could suit you.
> 
> There is a port of GNU-C to DOS called DJGPP that I'm pretty familiar with.
> A few weeks ago I released a port of KA9Q NOS to DJGPP; it's up on my web
> page. Are you saying there is specific support for windows 95 in graphics
> (not dos) mode?

   For DOS I was speaking about DJGPP, not DDJ. Yes, the objective is 
to be able to build full GUI programs on Windows95 and NT. But I 
think it is not totally working. They are on Beta 16 There is 
information in 

        ftp://ftp.cygnus.com/pub/sac/gnuwin32

   I have read it in DrDobbs Journal pages 121-126.

    Eduardo EA2BAJ
Eduardo Jacob - Area de Ingenieria Telematica
Departamento de Electronica y Telecomunicaciones
ETSII y de IT               Tel: +34-(9)4-427 8055
UPV / EHU                   Fax: +34-(9)4-441 4041
Alda Urquijo s/n         E-mail: jtpjatae@bi.ehu.es
E-48013 - Bilbao (Spain)       : 100021,2212 Compuserve

From rwmcgwier@worldnet.att.net Thu Sep 12 07:00:36 1996
Received: from mtigwc02.worldnet.att.net (mailhost.worldnet.att.net [204.127.129.4]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id HAA20169 for <hfsig@tapr.org>; Thu, 12 Sep 1996 07:00:33 -0500 (CDT)
Received: from dad.ccr-p.ida.org ([207.146.141.132])
          by mtigwc02.worldnet.att.net (post.office MTA v2.0 0613 )
          with SMTP id AAA20415 for <hfsig@tapr.org>;
          Thu, 12 Sep 1996 12:00:00 +0000
Message-ID: <3237FA46.2C96@worldnet.att.net>
Date: Thu, 12 Sep 1996 07:55:50 -0400
From: Robert McGwier <rwmcgwier@worldnet.att.net>
Reply-To: rwmcgwier@worldnet.att.net
Organization: N4HY Software
X-Mailer: Mozilla 3.0b8Gold (Win95; I)
MIME-Version: 1.0
To: hfsig@tapr.org
Subject: Re: [HFSIG:1526] coding progress
References: <199609102303.QAA07499@servo.qualcomm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Phil Karn wrote:
> 
> Hello all,
> 
> I've been rather quiet here of late so I thought I'd mention what I've
> been doing in my spare time over the past couple of weeks.
> 
> I've continued to fine-tune my Viterbi decoder for speed and Eb/N0
> performance.
> 


I saw a brilliant talk by Bob McEliece yesterday at the retirement bash
for
Neal Zierler.  It was on Turbo Codes.  I have a good understanding of
what
they are about now, maybe even better than McEliece ;-).  He has built
an
intuitive understanding of WHY they work but cannot prove it.  It is
closely
enough related to some stuff that I have done that I believe I CAN prove
why they work and I have some techniques at my disposal that will allow
me
to accelerate their convergence.  He claims that Viterbi claims they are
the most significant development in N years (where N closely matches the
number of years since he development the Viterbi decoder).  You and I
have
had a conversation before on the telephone where I told the win of
a posteriori estimation over dynamic programming based estimation.  Let
me
reemphasize it here since it is at the very heart of Turbo codes. 
Dynamic
programming (Viterbi decoding) finds the best PATH through the possible
paths of symbols.  What you want is to minimize the probability of
making
an error at each decision time given all the available evidence.  It is
this that Hidden Markov Models do (where the symbol is the Markov chain
and the noisy channel is providing the Hidden ;-).  Turbo codes have at
their heart, HMM, and the decoder approximates the EM algorithm (which
was first developed here at my company and the first rigorous proofs
concerning it were made by Baum, Petrie, Soules, and Welch while working
here).  My experiments show that Turbo codes get <<<<<<  within 1 dB of
the Shannon limit and indeed get in a case I have tried to -0.6 dB Eb/N0
>>>>>>>.  You must climb onto the power curve on this it IS the future
of coding.  I posted this to everyone since you appear to be ham radio's
primary instructor on coding these days and everyone could benefit by
discussions.

Bob
*************************************************************************
* Robert W. McGwier, Ph.D. * Mathematician. Hobbies: Computers,
Astronomy*
* 64 Brooktree Rd.         * Amateur Radio. Scouts: Council Commissioner
*
* East Windsor, NJ 08520   * Post 995 Advisor, Troop 5700 Advancement,  
*
* (H) 609-443-8963         * Sanhican #2 (Brotherhood), Used to be a    
*
* (F) 609-924-3061         * Buffalo (NE-III-120).  George Washington   
*
* (W) 609-279-6240         * Council.  Brownie Troop 193                
*
**************************************************************************

From karn@qualcomm.com Thu Sep 12 13:23:12 1996
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id NAA05011 for <hfsig@tapr.org>; Thu, 12 Sep 1996 13:23:10 -0500 (CDT)
Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id LAA28123; Thu, 12 Sep 1996 11:22:38 -0700 (PDT)
Date: Thu, 12 Sep 1996 11:22:38 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199609121822.LAA28123@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <199609120636.XAA12565@PEAK.ORG> (forrerj@peak.org)
Subject: Re: [HFSIG:1531] Re: coding progress

>Metrics.c: erf() .... not recognized perhaps there is an equivalent.
>
>           M_SQRT2, M_LOG2E .... not recognized - these are UNIX/GCC natives.

>Sim.c:     random() ... does'nt recognize this either.

Ah, those are both support files, not the actual decoder...

erf() is in the UNIX math library, and should be in most PC subroutine
libraries. It's the gaussian error function and is used to build the
metric tables from "first principles", i.e., from a knowledge of the
channel transition probabilities that are a function of Eb/N0 and amplitude.

M_SQRT2 and M_LOG2E are constants usually defined in <math.h>. M_SQRT2
is sqrt(2) and M_LOG2E is log2(e).

random() is a random number generator returning a value between 0 and
0x7fffffff inclusive. It's used to generate random bits and gaussian
noise for test purposes.

I note that the metric table can be built "offline" e.g., on a UNIX
system or under DJGPP with a math package and then the table(s)
included as compile-time data in the final program. Although the Fano
decoder works best when you compute a metric table for the actual
Eb/N0, I've found experimentally that you can use a fixed table
computed for the worst Eb/N0 you can handle (the computational cutoff
rate, about 2.5 dB for rate 1/2) and then scale the incoming signal to
maintain the constant noise level used to build the metric table. Much
stronger signals will saturate the soft-decision samples and
effectively degrade the decoder to hard decision decoding, but if
they're that strong and clean in the first place that won't hurt
anything. And signals noiser than 2.5 dB, of course, won't decode
anyway.

In other words, don't worry about the signal amplitude, it's the noise
amplitude that counts.

That's because the most important thing with the fano decoder is that
the branch metrics on the correct path be generally positive. If the
signal level is too low for the metric table in use, then the decoder
will constantly back up thinking it has made an error when in fact
it's on the best path.  That's why it's important to scale the
incoming signal to attempt to keep the noise level constant. That also
explains why a signal AGC is a *very bad* idea in Fano decoding, if it
causes the noise level to vary. You want to keep the noise level
constant and let the signal level vary if it has to.  Again, let the
signal saturate if it gets strong, that won't hurt anything.

One of the big advantages of the Viterbi decoder over the Fano
decoder, btw, is that the Viterbi decoder works for just about any
metric table, as long as it's not "upside down", i.e., as long as its
matched to the signal polarity. Even the set of integers 0-255 seems
to work well. As long as the signal amplitude is such as to use at
least a few bits of your sample dynamic range, the algorithm will
function reasonably optimally.


Phil



From karn@qualcomm.com Thu Sep 12 13:25:25 1996
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id NAA05063 for <hfsig@tapr.org>; Thu, 12 Sep 1996 13:25:23 -0500 (CDT)
Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id LAA28126; Thu, 12 Sep 1996 11:24:51 -0700 (PDT)
Date: Thu, 12 Sep 1996 11:24:51 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199609121824.LAA28126@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <m0v162e-000TyBC@bogomips.com> (jmorriso@bogomips.com)
Subject: Re: [HFSIG:1532] Re: coding progress

Thanks for the info on GCC under windows. Of course, the question
remains: is it possible to write anything approaching "real time" code
under that system, as opposed to running under DOS on a bare machine?
You can alleviate the problem with buffering (e.g., on a sound
card). But I've already seen at least one machine running W95 (my
laptop) that stutters occasionally like Max Headroom when playing back
audio, probably because of missed interrupts. It never did that under
W 3.1.

Phil

From karn@qualcomm.com Thu Sep 12 13:29:57 1996
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id NAA05200 for <hfsig@tapr.org>; Thu, 12 Sep 1996 13:29:54 -0500 (CDT)
Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id LAA28130; Thu, 12 Sep 1996 11:29:23 -0700 (PDT)
Date: Thu, 12 Sep 1996 11:29:23 -0700 (PDT)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199609121829.LAA28130@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <3237FA46.2C96@worldnet.att.net> (message from Robert McGwier on Thu, 12 Sep 1996 07:13:33 -0500 (CDT))
Subject: Re: [HFSIG:1534] Re: coding progress

I agree, turbo codes are very exciting and they probably represent
coding's last gasp. I've heard both Viterbi and McEliece speak at
Qualcomm on this subject.

But there's a catch. Patents are flying in this area faster than
bullets in a battlefield, and since I'm interested in writing free
software the last thing I want is to be sued.  Fano decoders, Viterbi
decoders, Reed-Solomon decoders and concatenated codes have been
around for 25-35 years and are clearly in the public domain.

Phil

From forrerj@peak.org  Thu Sep 12 16:16:56 1996
Received: from PEAK.ORG (root@PEAK.ORG [198.68.22.17]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id QAA12990 for <hfsig@tapr.org>; Thu, 12 Sep 1996 16:16:52 -0500 (CDT)
Received: from p06.t0.monrotel.com (p06.t0.monrotel.com [198.68.25.39]) by PEAK.ORG (8.6.13/8.6.7) with SMTP id OAA18381 for <hfsig@tapr.org>; Thu, 12 Sep 1996 14:17:00 -0700
Message-Id: <199609122117.OAA18381@PEAK.ORG>
X-Sender: forrerj@peak.org
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 12 Sep 1996 14:10:55 -0800
To: hfsig@tapr.org
From: forrerj@peak.org (Johan Forrer)
Subject: Re: [HFSIG:1532] Re: coding progress

John,


I checked this out and looks like an interesting development - they are at
Beta 16, but still is a cross-port running on a Linux platform. The native
compiler for the Win95 platform is still in it's infancy - will be a while
if I interpret things correctly.


>> There is a port of GNU-C to DOS called DJGPP that I'm pretty familiar with.
>> A few weeks ago I released a port of KA9Q NOS to DJGPP; it's up on my web
>> page. Are you saying there is specific support for windows 95 in graphics
>> (not dos) mode?
>
>Cygnus support sponsored a port to Windows NT, plus compatibility
>libraries to make UNIX programs easy to port. Windows 95 implements
>some of the Windows NT (Win32) API, so it runs under that too
>(but not as well apparently).
>
>I think it can only do console mode (ie text), more code needs
>to be written so GCC can create GUI apps.
>
>> 
>> Phil
>> 
>> 
>
>---------------------------------------------------------------------------
>BogoMIPS Research Labs  --  bogosity research & simulation  --  VE7JPM  -- 
>  jmorriso@bogomips.com  ve7jpm@ve7jpm.ampr.org  jmorriso@ve7ubc.ampr.org
>---------------------------------------------------------------------------
>
>

--Johan

From jmorriso@bogomips.com  Thu Sep 12 23:29:31 1996
Received: from orange.ConcordPacific.Com (root@orange.ConcordPacific.com [204.239.26.10]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id XAA10218 for <hfsig@tapr.org>; Thu, 12 Sep 1996 23:29:28 -0500 (CDT)
Received: from bogomips.com (root@jmorriso.multiactive.com [204.239.26.200]) by orange.ConcordPacific.Com (8.6.12/8.6.12) with SMTP id VAA18942 for <hfsig@tapr.org>; Thu, 12 Sep 1996 21:29:47 -0700
Received: by bogomips.com (Linux Smail3.1.29.1 #3)
	id m0v1Pql-000TswC; Thu, 12 Sep 96 21:27 PDT
Message-Id: <m0v1Pql-000TswC@bogomips.com>
From: jmorriso@bogomips.com (John Paul Morrison)
Subject: Re: [HFSIG:1538] Re: coding progress
To: hfsig@tapr.org
Date: Thu, 12 Sep 1996 21:27:29 -0700 (PDT)
In-Reply-To: <199609122117.OAA18381@PEAK.ORG> from "Johan Forrer" at Sep 12, 96 04:33:23 pm
X-Bogomips: 33.55
Content-Type: text

> 
> John,
> 
> 
> I checked this out and looks like an interesting development - they are at
> Beta 16, but still is a cross-port running on a Linux platform. The native
> compiler for the Win95 platform is still in it's infancy - will be a while
> if I interpret things correctly.
> 
> --Johan

GCC is not yet self-hosting on Win95/WinNT (ie can recompile itself)
but it does compile programs (actually, I think it will build itself
with some manual assistance). Also, I don't think Windows 95 is the
primary goal of the Win32 port. It's meant to work with Windows NT;
the Windows 95 support is a secondary bonus because it supports
some of the Win32 api, but not others. 

Depending on what you want to do, DJGPP programs work in Windows 95.
I was able to run the DJGPP version of NOS (which I cross-compiled in
Linux) in Windows 95, and use SLIP. Packet drivers should work too.

> 
> 

---------------------------------------------------------------------------
BogoMIPS Research Labs  --  bogosity research & simulation  --  VE7JPM  -- 
  jmorriso@bogomips.com  ve7jpm@ve7jpm.ampr.org  jmorriso@ve7ubc.ampr.org
---------------------------------------------------------------------------

From sailer@ife.ee.ethz.ch Fri Sep 13 09:34:46 1996
Received: from ife.ee.ethz.ch (ife-ife2.ee.ethz.ch [129.132.25.129]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id JAA03507 for <hfsig@tapr.org>; Fri, 13 Sep 1996 09:34:36 -0500 (CDT)
Received: from eldrich.ee.ethz.ch (eldrich.ee.ethz.ch [129.132.25.145]) by ife.ee.ethz.ch (8.7.5/8.7.5) with SMTP id QAA02316 for <hfsig@tapr.org>; Fri, 13 Sep 1996 16:34:31 +0200 (MET DST)
Sender: sailer@ife.ee.ethz.ch
Message-ID: <323970F5.35E5@ife.ee.ethz.ch>
Date: Fri, 13 Sep 1996 16:34:29 +0200
From: Thomas Sailer <sailer@ife.ee.ethz.ch>
Organization: IfE
X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4m)
MIME-Version: 1.0
To: hfsig@tapr.org
Subject: Re: [HFSIG:1536] Re: coding progress
References: <199609121824.LAA28126@servo.qualcomm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> card). But I've already seen at least one machine running W95 (my
> laptop) that stutters occasionally like Max Headroom when playing back
> audio, probably because of missed interrupts. It never did that under
> W 3.1.
This seems to be a different problem. We're currently working
on Windows support for PC/FlexNet, and Baycom type modems and (U)SCC
cards at higher speeds run already, which have rather hard
requirements wrt interrupt latency.
Not that I am a Windoze advocat...

Tom

From forrerj@peak.org  Mon Sep 23 10:49:48 1996
Received: from PEAK.ORG (root@PEAK.ORG [198.68.22.17]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id KAA20613 for <HFSIG@TAPR.org>; Mon, 23 Sep 1996 10:49:47 -0500 (CDT)
Received: from p03.t0.monrotel.com (p00.t0.monrotel.com [198.68.25.33]) by PEAK.ORG (8.6.13/8.6.7) with SMTP id IAA27272 for <HFSIG@TAPR.org>; Mon, 23 Sep 1996 08:49:58 -0700
Message-Id: <199609231549.IAA27272@PEAK.ORG>
X-Sender: forrerj@peak.org
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 23 Sep 1996 08:45:26 -0800
To: HFSIG@tapr.org
From: forrerj@peak.org (Johan Forrer)
Subject: DCC 1996

Hi All,

I will shortly post a short summary of my impressions of the recent DCC. 

First; let me thank the hosts; BEARS (Boeing Employees Amateur Radio
Society) for all the kind and generous hospitality. The conference venue was
excellent, food great, and we were kept entertained and happy. 

I also wish to thank ARRL and the folks from TAPR for all the hard work that
have gone into making such an event successful. Just to illustrate; the
proceedings consists of some 256 double-sided pages with excellent technical
content, for example, two outstanding contributions on 1.2 Mbit/s digital
tranceivers by Matjaz Vidmar, S53MV - complete with schematics.

The interest in HF digital was heartwarming and so was the HFSIG meeting (at
least from where I was standing on the other side of the podium!) The topic
this time was woven around past discussions we have had on HFSIG regarding
HF Channel simulation: Tom McDermot did an excellent presentation of the
mechnics involved in simulation using the Watterson model, that I followed
with showing a number of "doppler grams", courtesy of Peter Martinez, G3PLX.
These are really unique and worth seeing. A brief overview of software for
the DSP-93 and a demo running this implementation of the Watterson
ionospheric model, concluded this part of the meeting. I also presented an
outline of the work that I have been doing on QUATOR.

More to follow later on the DCC. 

I also need to prepare a posting on some of the recent developments on the
slow-speed BPSK scene - this involves some innovative coding that are
especially suited for such narrow-band systems that are limited by human
typing speeds - quite contrary to the trend to building error-correcting
codes.   

73's till later.

--Johan Forrer, KC7WW 

From forrerj@peak.org  Tue Sep 24 10:50:07 1996
Received: from PEAK.ORG (root@PEAK.ORG [198.68.22.17]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id KAA04954 for <HFSIG@TAPR.ORG>; Tue, 24 Sep 1996 10:50:05 -0500 (CDT)
Received: from p06.t0.monrotel.com (p06.t0.monrotel.com [198.68.25.39]) by PEAK.ORG (8.6.13/8.6.7) with SMTP id IAA09227 for <HFSIG@TAPR.ORG>; Tue, 24 Sep 1996 08:50:03 -0700
Message-Id: <199609241550.IAA09227@PEAK.ORG>
X-Sender: forrerj@peak.org
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 24 Sep 1996 08:45:42 -0800
To: HFSIG@tapr.org
From: forrerj@peak.org (Johan Forrer)
Subject: G3PLX's Dopplergrams

Hi,

I have had someone ask to post further details about how the dopplergrams
that I showed at the DCC were produced.

Actually it's an old trick used in monitoring meteor scatter and other weak
signals; monitor a known transmission that you know arrives via the ionosphere. 
        Peter's examples where recorded on 21 MHz, 17.7 MHz, 10.2 MHz, 7.7
MHz, and 3.5 MHz. Then a slice of the receiver's audio passband, say around
1 kHz are converted into a stream of I/Q values at 10 mS intervals and that
run through an FFT to produce the images. Peter then describes the display
as follow:
 
        "These images are time/frequency plots, with signal-level encoded 
         as the brightness. They were originally 16-level, and the signal 
         level is logarithmic with 3.75dB per grey-step, so that the full 
         dynamic range is 60dB. In the vertical direction there are 256 pixels
         representing the frequency axis, and in most of the images there 
         are 640 pixels horizontally for the time-axis."

The result appears like a strip chart with Doppler shift on the vertical
axis, and time along the horizontal axis. The doppler axis typically spans
256 pixels that represent either 25 Hz, 12.5 Hz, or 6.25 Hz Doppler, i.e.,
tracking some rather narrow frequency disturbances. The time axis typically
spans over several hours, often a full day and night. In such cases band
"closing" and "openings" are distinct and reveal several complex ionospheric
mechanics such as meteor pings, sporadic E, F layer propagation, and rays
splitting into (O)rdinary and (X)traordinary components. Even reflections
from aircraft can be identified.

Peter indicated that he will be publishing some of this work and that would
be something to look forward to. We are most grateful for his permission to
show some examples of this work at the DCC.  

--Johan

From nuucp@ihig2.firewall.lucent.com Tue Sep 24 12:02:50 1996
Received: from ihgw2.lucent.com (ihgw2.att.com [207.19.48.2]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id MAA06824 for <hfsig@tapr.org>; Tue, 24 Sep 1996 12:02:49 -0500 (CDT)
To: hfsig@tapr.org
Received: by ihig2.firewall.lucent.com (SMI-8.6/EMS-L sol2)
	id LAA05191; Tue, 24 Sep 1996 11:58:36 -0500
Date: Tue, 24 Sep 1996 11:58:36 -0500
From: nuucp@ihig2.firewall.lucent.com
Message-Id: <199609241658.LAA05191@ihig2.firewall.lucent.com>
Subject: UUCP command execution failed
Content-Type: text
Apparently-To: tapr.org!hfsig@ihig2.firewall.lucent.com

Your UUCP remote execution request 'igbAbb3e' (9/24-11:58:35)
failed on system 'ihig2'.
Your request: rmail bighorn.dr.lucent.com!grb 
Reason for failure: command exited with exit code 1


From karn@unix.ka9q.ampr.org Fri Sep 27 03:20:02 1996
Received: from unix.ka9q.ampr.org (karn@unix.ka9q.ampr.org [129.46.90.35]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id DAA15212 for <hfsig@tapr.org>; Fri, 27 Sep 1996 03:20:00 -0500 (CDT)
Received: (from karn@localhost) by unix.ka9q.ampr.org (8.7.4/8.7.3) id BAA16824; Fri, 27 Sep 1996 01:19:42 -0700 (PDT)
Date: Fri, 27 Sep 1996 01:19:42 -0700 (PDT)
Message-Id: <199609270819.BAA16824@unix.ka9q.ampr.org>
From: Phil Karn <karn@unix.ka9q.ampr.org>
To: hfsig@tapr.org, tcp-group@ucsd.edu
Cc: robert@spectra.eng.hawaii.edu, harit@spectra.eng.hawaii.edu,
        simon@augean.eleceng.adelaide.edu.au
Subject: Reed-Solomon encoder/decoder code available

Hi. I've just released the Reed-Solomon software I've been working on
lately.

The software can encode and decode Reed-Solomon codes with symbol
sizes ranging from 2^2 to 2^16 bits. The default parameters are for
the (255,223) code with 8-bit symbols that was used on the Voyager-2
spacecraft at Uranus and Neptune.

The files are as follows:

http://www.qualcomm.com/people/pkarn/feccode/rs-readme
http://www.qualcomm.com/people/pkarn/feccode/rs.zip
http://www.qualcomm.com/people/pkarn/feccode/rs.tar.gz

I've also updated my ham radio digital communications page
(http://www.qualcomm.com/people/pkarn/ham.html) with pointers to these
files. Enjoy!

Phil



From jsanford@mailhost.infi.net Fri Sep 27 07:10:14 1996
Received: from mh004.infi.net (mh004.infi.net [198.22.1.119]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id HAA20137 for <hfsig@tapr.org>; Fri, 27 Sep 1996 07:10:12 -0500 (CDT)
Received: from PENTIUM by mh004.infi.net with SMTP 
	(Infinet-S-3.3) id IAA13490; Fri, 27 Sep 1996 08:10:20 -0400 (EDT)
Message-ID: <324BBF42.6A57@mailhost.norfolk.infi.net>
Date: Fri, 27 Sep 1996 07:49:22 -0400
From: Jim Sanford <jsanford@mailhost.infi.net>
Reply-To: WB4GCS@AMSAT.ORG
Organization: wb4gcs@amsat.org
X-Mailer: Mozilla 3.0 (Win16; U)
MIME-Version: 1.0
To: hfsig@tapr.org
Subject: Re: [HFSIG:1544] Reed-Solomon encoder/decoder code available
References: <199609270819.BAA16824@unix.ka9q.ampr.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Phil Karn wrote:
> 
> Hi. I've just released the Reed-Solomon software I've been working on
> lately.
> 
> The software can encode and decode Reed-Solomon codes with symbol
> sizes ranging from 2^2 to 2^16 bits. The default parameters are for
> the (255,223) code with 8-bit symbols that was used on the Voyager-2
> spacecraft at Uranus and Neptune.
> 
> The files are as follows:
> 
> http://www.qualcomm.com/people/pkarn/feccode/rs-readme
> http://www.qualcomm.com/people/pkarn/feccode/rs.zip
> http://www.qualcomm.com/people/pkarn/feccode/rs.tar.gz
> 
> I've also updated my ham radio digital communications page
> (http://www.qualcomm.com/people/pkarn/ham.html) with pointers to these
> files. Enjoy!
> 
> Phil
Phil:
THANK YOU!

All the best 73, Jim wb4gcs@amsat.org

From forrerj@peak.org  Fri Sep 27 10:12:18 1996
Received: from PEAK.ORG (root@PEAK.ORG [198.68.22.17]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id KAA25641 for <hfsig@tapr.org>; Fri, 27 Sep 1996 10:12:16 -0500 (CDT)
Received: from p05.t0.monrotel.com (p05.t0.monrotel.com [198.68.25.38]) by PEAK.ORG (8.6.13/8.6.7) with SMTP id IAA04514 for <hfsig@tapr.org>; Fri, 27 Sep 1996 08:12:27 -0700
Message-Id: <199609271512.IAA04514@PEAK.ORG>
X-Sender: forrerj@peak.org
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 27 Sep 1996 08:08:29 -0800
To: hfsig@tapr.org
From: forrerj@peak.org (Johan Forrer)
Subject: Re: [HFSIG:1544] Reed-Solomon encoder/decoder code available

Phil,

>Hi. I've just released the Reed-Solomon software I've been working on
>lately.


Great! I have just the application for it.

Thanks much.

--Johan

From jsanford@mailhost.infi.net Fri Sep 27 12:06:17 1996
Received: from mh004.infi.net (mh004.infi.net [198.22.1.119]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id MAA00251 for <hfsig@tapr.org>; Fri, 27 Sep 1996 12:06:16 -0500 (CDT)
Received: from PENTIUM by mh004.infi.net with SMTP 
	(Infinet-S-3.3) id NAA28883; Fri, 27 Sep 1996 13:06:24 -0400 (EDT)
Message-ID: <324C0980.14F1@mailhost.norfolk.infi.net>
Date: Fri, 27 Sep 1996 13:06:08 -0400
From: Jim Sanford <jsanford@mailhost.infi.net>
Reply-To: WB4GCS@AMSAT.ORG
Organization: wb4gcs@amsat.org
X-Mailer: Mozilla 3.0 (Win16; U)
MIME-Version: 1.0
To: hfsig@tapr.org
Subject: Re: [HFSIG:1544] Reed-Solomon encoder/decoder code available
References: <199609270819.BAA16824@unix.ka9q.ampr.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> 
> The files are as follows:
> 
> http://www.qualcomm.com/people/pkarn/feccode/rs-readme
> http://www.qualcomm.com/people/pkarn/feccode/rs.zip
> http://www.qualcomm.com/people/pkarn/feccode/rs.tar.gz
> 
> Phil
Phil:
What's the rs.zip and rs.tar.gz files -- different coding of same thing?
Netscape choked on the .gz file . . . . 
  (Windoze version)

thanks, Jim

From rwhiting@winternet.com Sun Sep 29 20:04:49 1996
Received: from icicle.winternet.com (adm@icicle.winternet.com [198.174.169.5]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id UAA18451 for <hfsig@tapr.org>; Sun, 29 Sep 1996 20:04:46 -0500 (CDT)
Received: (from adm@localhost) by icicle.winternet.com (8.7.5/8.7.5) id UAA02558 for <hfsig@tapr.org>; Sun, 29 Sep 1996 20:04:42 -0500 (CDT)
Date: Sun, 29 Sep 1996 20:04:42 -0500 (CDT)
Posted-Date: Sun, 29 Sep 1996 20:04:42 -0500 (CDT)
Message-Id: <199609300104.UAA02558@icicle.winternet.com>
Received: from ppp-67-117.dialup.winternet.com(204.246.67.117) by icicle.winternet.com via smap (V2.0a1)
	id xma002539; Sun, 29 Sep 96 20:04:28 -0500
X-Sender: rwhiting@mail.winternet.com
X-Mailer: Windows Eudora Light Version 1.5.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: hfsig@tapr.org
From: CDrentea@aol.com (by way of Rick Whiting <rwhiting@winternet.com>)
Subject: New Book

I came across a new book you may want to take a look at:  Digital
Communications Techniques - Signal Design and Detection by Simon, Hinedi and
Lindsey - ISBN # 0-13-200610-3.  It has been recently published by Prentice
Hall and costs about $82 - 10% from Barnes and Noble.

Very comprehensive.  Although this information exists partially in other
books, the book presents the methods of coherent, noncoherent, partially
coherent, and differentially coherent detection for various binary and M-ary
coded and uncoded modulation techniques (BPSK, QPSK, MSK, MFSK, QASK, QAM,
etc) that can be applied to the design of uncoded systems while the
Ro-criterion (channel throughput in bits/sec/Hz) and bit error probability
are used as the methodology for designing efficient coded digital radio
communications circuits.  The book has absolutely nothing on propagation
phenomena per say (it would be too good to be true), but presents the
communication channel methodically and much like an OSI-ISO seven layer
digital communications model (old stuff for data communications in WANs and
LANs, but a very "novel" idea for radio data communications).

Key concepts include scalar, vector, and waveform communications over the
additive nonwhite (colored) Gaussian noise channels.  Communications via
Rayleigh and Rician fading (due to multipath) channels are also presented. 

Enjoy!




From karn@unix.ka9q.ampr.org Mon Sep 30 03:55:29 1996
Received: from unix.ka9q.ampr.org (karn@unix.ka9q.ampr.org [129.46.90.35]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id DAA09525 for <hfsig@tapr.org>; Mon, 30 Sep 1996 03:55:27 -0500 (CDT)
Received: (from karn@localhost) by unix.ka9q.ampr.org (8.7.4/8.7.3) id BAA23664; Mon, 30 Sep 1996 01:54:48 -0700 (PDT)
Date: Mon, 30 Sep 1996 01:54:48 -0700 (PDT)
Message-Id: <199609300854.BAA23664@unix.ka9q.ampr.org>
From: Phil Karn <karn@unix.ka9q.ampr.org>
To: Jim Sanford <jsanford@mailhost.infi.net>
CC: hfsig@tapr.org
Reply-To: karn@qualcomm.com
In-reply-to: <324C0980.14F1@mailhost.norfolk.infi.net> (message from Jim
	Sanford on Fri, 27 Sep 1996 12:15:17 -0500 (CDT))
Subject: Re: [HFSIG:1547] Re: Reed-Solomon encoder/decoder code available

>What's the rs.zip and rs.tar.gz files -- different coding of same thing?

Yes. The rs.zip file is a PKZIP-format file (primarily for DOS users) and
the rs.tar.gz file is a GZIP-compressed tar archive (primarily for UNIX users).
I say "primarily" because tools to read each format do exist on both platforms.

Note that the test driver program is intended for a UNIX environment
and may require some tweaking to run under DOS, e.g, the library
routines called to generate random numbers may have to be changed.

The actual RS subroutines are self-contained and should compile
cleanly on any system that supports ANSI C.

Phil

